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Real party in interest 

Asset Reliance, Inc. (dba Asset Trust, Inc.) 

Related appeals 

An appeal for U.S. Patent Application 09/761,670 filed January 18, 2001 may be affected or have a 
bearing on this appeal. An appeal for U.S. Patent Application 09/761,671 filed January 18, 2001 
may be affected or have a bearing on this appeal. U.S. Patent Application 10/282,113 filed 
October 29, 2002 may be affected or have a bearing on this appeal. 

Status of Claims 

Claims 44 - 59 and 65 - 81 are rejected and are the subject of this appeal. Claims 44, 47, 53, 65, 
67, 71 and 77 are amended. Claims 1 - 43 and 60 - 64 are cancelled without prejudice. Claim 82 
is withdrawn because of a restriction requirement. 

Status of Amendments 

An Amendment/Reply containing the amendments to claims 44, 47, 53, 65, 67, 71 and 77 was 
submitted on November 30, 2007. 
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Summary of Claimed Subject Matter 

One embodiment of a method of and system for analyzing, modeling and valuing elements of a 
business enterprise according to the present invention is best depicted in Figures 1 - 15 of the 
specification for the instant application. Figure 1 gives an overview of the major processing steps 
which include converting and storing data from a plurality of database management systems for 
use in analysis, analyzing the data as required to: optionally value growth options, identify value 
drivers by element of value, develop a predictive model for each component of enterprise value 
and value the elements of value. 

Independent Claim 44 - One embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 44 where an article of 
manufacture guides the conversion and storage of data aggregated from a plurality of 
management systems in accordance with a common schema. The aggregated data are then used 
to develop a model of enterprise cash flow by element of value and component of value. The 
model of enterprise cash flow by element and component of value is then used to determine the 
current operation value of one or more elements of value. More specifically, data from the 
database management systems associated with a plurality of enterprise transaction systems are 
aggregated and stored in one or more tables or files in accordance with a network schema as 
described FIG. 1 reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference 
numbers 221 - 223, 225 - 230, FIG. 10 reference numbers 710 - 1 through 710 - n, 720-1 
through 720 - n and 730 and line 16, page 18 through line 16, page 35 of the specification. The 
aggregated data are then analyzed using a series of models in order to identify the attributes of 
each element of value that contribute to the value of each component of value and identify sub- 
elements of value for each element of value. The identified attributes are then used to develop 
element and sub-element of value impact summaries in accordance with the procedure detailed in 
FIG. 6A reference number 302 - 305, 306 - 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B 
reference numbers 312 - 315, 325, 330, 335, 340, 345, 350 and 355, FIG. 6C reference numbers 
319, 321 - 323, 326 - 329, 332 and 375 , FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 
309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6E reference numbers 352 - 354, 315, 325, 330, 
335, 340, 345, 350 and 355, and line 15, page 35 through line 14, page 53 of the specification. 
The capitalized value of the components of value and the current operation are then determined as 
shown in FIG. 8 reference number 503 - 512, 514 and 515 and line 18, page 56 through Iine15, 
page 59 of the specification. The previously identified element of value impact summaries are then 
used as inputs to neural network models of the components of value (revenue, expense and 
capital change) as described in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 604, 625 and 
630, FIG. 9B reference numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, FIG. 9C 
reference 325, 330, 335, 340, 611, 613, 614, 625 and 630 and line 16, page 59 through line 5, 
page 62 of the specification. The weights from the neural network models are then used to 
determine the percentage of each component of value that is caused by the impact of each 
element of value before the percentages are combined with the capitalized values of the 
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components of value to determine the current operation value contribution of each element of 
value as described in FIG. 12 reference number 772 - 782 and line 7, page 62 through line 25, 
page 65 of the specification. The models used to determine the value impact of each element of 
value are also use for: predicting an impact of a change to one or more elements of value on 
enterprise cash flow, identifying a set of changes to one or more elements of value that will 
optimize enterprise cash flow and producing financial statements that identify value and value 
changes by element of value. 

Dependent claims 

The limitations associated with dependent claim 45 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

The limitations associated with dependent claim 46 are described in several places including 
line 16, page 56 through line 9, page 59 of the specification. 

The limitations associated with dependent claim 47 are described in several places including 
table 1, page 9, and Table 16, page 31 of the specification. 

The limitations associated with dependent claim 48 are described in line 1, page 26 through line 
14, page 26. 

The limitations associated with dependent claim 49 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 50 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 51 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 52 are described in a variety of places including 
FIG. 10. 

Independent Claim 53 - A second embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 53 where a process converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
schema. The aggregated data are then used to develop a model of enterprise cash flow by 
element of value and component of value that is used to calculate the current operation value 
contribution for each element of value. More specifically, data from the database management 



Serial No: 08/999,245 



5 



systems associated with a plurality of enterprise transaction systems are aggregated and stored in 
one or more tables or files in accordance with a network schema as described FIG. 1 reference 
number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference numbers 221 - 223, 225 - 
230, FIG. 10 reference numbers 710-1 through 710 - n, 720-1 through 720 - n and 730 and line 
16, page 18 through line 16, page 35 of the specification. The aggregated data are then analyzed 
using a series of models in order to identify the attributes of each element of value that contribute 
to the value of each component of value and identify sub-elements of value for each element of 
value. The identified attributes are then used to develop element and sub-element of value impact 
summaries in accordance with the procedure detailed in FIG. 6A reference number 302 - 305, 306 
- 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B reference numbers 312 - 315, 325, 330, 
335, 340, 345, 350 and 355, FIG. 6C reference numbers 319, 321 - 323, 326 - 329, 332 and 375 , 
FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 309, 325, 330, 335, 340, 345, 350 and 355, 
FIG. 6E reference numbers 352 - 354, 315, 325, 330, 335, 340, 345, 350 and 355, and line 15, 
page 35 through line 14, page 53 of the specification. The capitalized value of the components of 
value and the current operation are then determined as shown in FIG. 8 reference number 503 - 
512, 514 and 515 and line 18, page 56 through Iine15, page 59 of the specification. The previously 
identified element of value impact summaries are then used as inputs to neural network models of 
the components of value (revenue, expense and capital change) as described in FIG. 9A reference 
numbers 325, 330, 335, 340, 602 - 604, 625 and 630, FIG. 9B reference numbers 325, 330, 335, 
340, 605, 607, 608, 625 and 630, FIG. 9C reference 325, 330, 335, 340, 611, 613, 614, 625 and 
630 and line 16, page 59 through line 5, page 62 of the specification. The weights from the neural 
network models are then used to determine the percentage of each component of value that is 
caused by the impact of each element of value before the percentages are combined with the 
capitalized values of the components of value to determine the current operation value contribution 
of each element of value as described in FIG. 12 reference number 772 - 782 and line 7, page 62 
through line 25, page 65 of the specification. The calculated values are then used to produce 
financial statements that include the calculated current operation values for the element of values 
as described in FIG. 13 reference number 802 - 806 and line 26, page 65 through line 32, page 
67. 

Dependent claims 

The limitations associated with dependent claim 54 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

The limitations associated with dependent claim 55 are described in several places including 
table 1, page 9, and Table 16, page 31 of the specification. 

The limitations associated with dependent claim 56 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 
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The limitations associated with dependent claim 57 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 58 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 59 are described in several places including 
FIG. 10. 

Independent Claim 65 - A third embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 65 where a process converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
schema. The aggregated data are then used to develop a model of enterprise cash flow by 
element of value and component of value that is then used to identify and optimal set of changes to 
the elements of value. More specifically, data from the database management systems associated 
with a plurality of enterprise transaction systems are aggregated and stored in one or more tables 
or files in accordance with a network schema as described FIG. 1 reference number 200, FIG. 5A 
reference numbers 201 - 213, FIG. 5B reference numbers 221 - 223, 225 - 230, FIG. 10 reference 
numbers 710-1 through 710 - n, 720-1 through 720 - n and 730 and line 16, page 18 through 
line 16, page 35 of the specification. The aggregated data are then analyzed using a series of 
models in order to identify one or more performance indicators for each element of value that 
contribute to the value of each component of value and identify sub-elements of value for each 
element of value. The identified performance indicators are then used to develop element and 
sub-element of value impact summaries in accordance with the procedure detailed in FIG. 6A 
reference number 302 - 305, 306 - 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B reference 
numbers 312 - 315, 325, 330, 335, 340, 345, 350 and 355, FIG. 6C reference numbers 319, 321 - 
323, 326 - 329, 332 and 375 , FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 309, 325, 
330, 335, 340, 345, 350 and 355, FIG. 6E reference numbers 352 - 354, 315, 325, 330, 335, 340, 
345, 350 and 355, and line 15, page 35 through line 14, page 53 of the specification. The 
capitalized value of the components of value and the current operation are then determined as 
shown in FIG. 8 reference number 503 - 512, 514 and 515 and line 18, page 56 through Iine15, 
page 59 of the specification. The previously identified element of value impact summaries are then 
used as inputs to neural network models of the components of value (revenue, expense and 
capital change) as described in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 604, 625 and 
630, FIG. 9B reference numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, FIG. 9C 
reference 325, 330, 335, 340, 611, 613, 614, 625 and 630 and line 16, page 59 through line 5, 
page 62 of the specification. The component of value models are then optimized using genetic 
algorithms as described using reference numbers 325, 330, 335, 340, 345, 350 and 355 from FIG. 
6A to identify changes to the elements of value that will optimize performance. Cross referenced 
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U.S. Patent 5,615,109 also describes an alternate method that could be used for identifying an 
optimal set of changes to the elements of value. 

Dependent claim 

The limitations and activities associated with dependent claim 66 are described in several 
places including FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 
and Table 16, page 31 of the specification. The activities comprise identifying a common set of 
attributes in a plurality of data dictionaries and aggregating data from a plurality of database 
management systems in accordance with said common attributes. 

Independent Claim 67 - A fourth embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 67 where an article of 
manufacture guides conversion and storage of event data from a plurality of management systems 
into an application database for use in processing. The aggregated data are then used to develop 
a model of enterprise cash flow by element of value and component of value that is used to 
forecast an impact of a response to an event. More specifically, data dictionaries from the 
database management systems associated with a plurality of enterprise transaction systems are 
obtained, relationships between the newly obtained data dictionaries and an application data 
dictionary are identified, these relationships are then used to guide the conversion and storage of 
data in one or more tables or files in accordance with a common schema in a common database 
as described FIG. 1 reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B 
reference numbers 221 - 223, 225 - 230, FIG. 10 reference numbers 710-1 through 710 - n, 
720-1 through 720 - n and 730 and line 16, page 18 through line 16, page 35 of the specification. 
The aggregated data are then analyzed using a series of models in order to identify the attributes 
of each element of value that contribute to the value of each component of value and identify sub- 
elements of value for each element of value. The identified attributes are then used to develop 
element and sub-element of value impact summaries in accordance with the procedure detailed in 
FIG. 6A reference number 302 - 305, 306 - 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B 
reference numbers 312 - 315, 325, 330, 335, 340, 345, 350 and 355, FIG. 6C reference numbers 
319, 321 - 323, 326 - 329, 332 and 375 , FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 
309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6E reference numbers 352 - 354, 315, 325, 330, 
335, 340, 345, 350 and 355, and line 15, page 35 through line 14, page 53 of the specification. 
The capitalized value of the components of value and the current operation are then determined as 
shown in FIG. 8 reference number 503 - 512, 514 and 515 and line 18, page 56 through Iine15, 
page 59 of the specification. The previously identified element of value impact summaries are then 
used as to develop neural network models of the components of value (revenue, expense and 
capital change) as described in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 604, 625 and 
630, FIG. 9B reference numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, FIG. 9C 
reference 325, 330, 335, 340, 611, 613, 614, 625 and 630 and line 16, page 59 through line 5, 
page 62 of the specification. Event data are then input to the neural network models of cash flow 
by component of value as required to forecast an impact of one or more events on financial 
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performance in a manner that is well known. An optimal response can be identified using the 
method detailed above for claim 65. 

Dependent claims 

The limitations associated with dependent claim 68 are described in several places including 
FIG. 10. 

The limitations associated with dependent claim 69 are described in several places including 
FIG. 10. 

The limitations associated with dependent claim 70 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

Independent claim 71 - A fifth embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 71 where a machine 
converts and stores data aggregated from a plurality of management systems in accordance with a 
common schema for use in processing. The aggregated data are then used to develop a model of 
enterprise cash flow by element of value and component of value. The model of enterprise cash 
flow by element and component of value is then used to determine the current operation value of 
one or more elements of value. More specifically, data dictionaries from the database management 
systems associated with a plurality of enterprise transaction systems are obtained, relationships 
between the newly obtained data dictionaries and an application data dictionary are identified, 
these relationships are then used to guide the conversion and storage of data in one or more 
tables or files in accordance with a common schema in a common database as described FIG. 1 
reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference numbers 221 - 
223, 225 - 230, FIG. 10 reference numbers 710-1 through 710 - n, 720-1 through 720 - n and 
730 and line 16, page 18 through line 16, page 35 of the specification. The aggregated data are 
then analyzed using a series of models in order to identify the attributes of each element of value 
that contribute to the value of each component of value and identify sub-elements of value for each 
element of value. The identified attributes are then used to develop element and sub-element of 
value impact summaries in accordance with the procedure detailed in FIG. 6A reference number 
302 - 305, 306 - 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B reference numbers 312 - 
315, 325, 330, 335, 340, 345, 350 and 355, FIG. 6C reference numbers 319, 321 - 323, 326 - 329, 
332 and 375 , FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 309, 325, 330, 335, 340, 345, 
350 and 355, FIG. 6E reference numbers 352 - 354, 315, 325, 330, 335, 340, 345, 350 and 355, 
and line 15, page 35 through line 14, page 53 of the specification. The capitalized value of the 
components of value and the current operation are then determined as shown in FIG. 8 reference 
number 503 - 512, 514 and 515 and line 18, page 56 through Iine15, page 59 of the specification. 
The previously identified element of value impact summaries are then used as inputs to neural 
network models of the components of value (revenue, expense and capital change) as described 
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in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 604, 625 and 630, FIG. 9B reference 
numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, FIG. 9C reference 325, 330, 335, 340, 
611, 613, 614, 625 and 630 and line 16, page 59 through line 5, page 62 of the specification. The 
weights from the neural network models are then used to determine the percentage of each 
component of value that is caused by the impact of each element of value before the percentages 
are combined with the capitalized values of the components of value to determine the current 
operation value contribution of each element of value as described in FIG. 12 reference number 
772 - 782 and line 7, page 62 through line 25, page 65 of the specification. The models used to 
determine the value impact of each element of value are also use for: predicting an impact of a 
change to one or more elements of value on enterprise cash flow, identifying a set of changes to 
one or more elements of value that will optimize enterprise cash flow and producing financial 
statements that identify value and value changes by element of value. 

Dependent claims 

The limitations associated with dependent claim 72 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. It is well known to those of average skill in the art that the databases for the listed 
systems are typically relational database systems. 

The limitations associated with dependent claim 73 are described in several places including 
FIG. 1, reference number 25 and line 15, page 12 through line 16 page 12 of the specification. 

The limitations associated with dependent claim 74 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 75 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

The limitations associated with dependent claim 76 are described in several places including 
line 12, page 8 through line 22, page 8 of the specification. 

Independent claim 77 A sixth embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 77 where a process converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
schema for use in processing. The aggregated data are then used to develop a model of 
enterprise cash flow by element of value and component of value that is used to calculate the 
current operation value contribution for each element of value. More specifically, data dictionaries 
from the database management systems associated with a plurality of enterprise transaction 
systems are obtained, relationships between the newly obtained data dictionaries and an 
application data dictionary are identified, these relationships are then used to guide the conversion 
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and storage of data in one or more tables or files in accordance with a common schema in a 
common database as described FIG. 1 reference number 200, FIG. 5A reference numbers 201 - 
213, FIG. 5B reference numbers 221 - 223, 225 - 230, FIG. 10 reference numbers 710 - 1 
through 710 - n, 720-1 through 720 - n and 730 and line 16, page 18 through line 16, page 35 of 
the specification. The aggregated data are then analyzed using a series of models in order to 
identify the attributes of each element of value that contribute to the value of each component of 
value and identify sub-elements of value for each element of value. The identified attributes are 
then used to develop element and sub-element of value impact summaries in accordance with the 
procedure detailed in FIG. 6A reference number 302 - 305, 306 - 309, 325, 330, 335, 340, 345, 
350 and 355, FIG. 6B reference numbers 312 - 315, 325, 330, 335, 340, 345, 350 and 355, FIG. 
6C reference numbers 319, 321 - 323, 326 - 329, 332 and 375 , FIG. 6D reference numbers 337 - 
339, 341 - 343, 305, 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6E reference numbers 352 - 
354, 315, 325, 330, 335, 340, 345, 350 and 355, and line 15, page 35 through line 14, page 53 of 
the specification. The capitalized value of the components of value and the current operation are 
then determined as shown in FIG. 8 reference number 503 - 512, 514 and 515 and line 18, page 
56 through Iine15, page 59 of the specification. The previously identified element of value impact 
summaries are then used as inputs to neural network models of the components of value (revenue, 
expense and capital change) as described in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 
604, 625 and 630, FIG. 9B reference numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, 
FIG. 9C reference 325, 330, 335, 340, 611, 613, 614, 625 and 630 and line 16, page 59 through 
line 5, page 62 of the specification. The weights from the neural network models are then used to 
determine the percentage of each component of value that is caused by the impact of each 
element of value before the percentages are combined with the capitalized values of the 
components of value to determine the current operation value contribution of each element of 
value as described in FIG. 12 reference number 772 - 782 and line 7, page 62 through line 25, 
page 65 of the specification. 

Dependent claims 

The limitations associated with dependent claim 78 are described in several places including 
FIG. 1, reference number 25 and line 15, page 12 through line 16 page 12 of the specification. 

The limitations associated with dependent claim 79 are described in several places including 
FIG. 1 , reference number 5 and line 20, page 12 of the specification. 

The limitations associated with dependent claim 80 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

The limitations associated with dependent claim 81 are described in table 1, page 9, Table 16, 
page 31 and line 20, page 18 through line 14, page 26 of the specification. 
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Grounds of rejection to be reviewed on appeal 



Issue 1 - Whether claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, claim 51 
and/or claim 52 are patentable under 35 USC 103(a) over U.S. Patent 4,989,141 (hereinafter, 
Lyons) with consideration to Database Management by Gordon C. Everest (hereinafter, Everest) ? 

Issue 2 - Whether claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 and/or claim 59 are 
patentable under 35 USC 103(a) over Lyons with consideration to Everest? 

Issue 3 - Whether claim 65 and/or claim 66 are patentable under 35 USC 103(a) over Lyons with 
consideration to Everest? 

Issue 4 - Whether claim 67, claim 68, claim 69 and/or claim 70 are patentable under 35 USC 
103(a) over Lyons with consideration to Everest? 

Issue 5 - Whether claim 71, claim 72, claim 73, claim 74, claim 75 and/or claim 76 are patentable 
under 35 USC 103(a) over Lyons with consideration to Everest? 

Issue 6 - Whether claim 77, claim 78, claim 79, claim 80 and/or claim 81 are patentable under 35 
USC 103(a) over Lyons with consideration to Everest? 
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The Argument 



Grouping of Claims 

For each ground of rejection which Appellant contests herein which applies to more than one 
claim, such additional claims, to the extent separately identified and argued below, do not stand 
and fall together. 

Issue 1 - Whether claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, claim 
51 and/or claim 52 are patentable under 35 USC 103(a) over Lyons with consideration to 
Everest? 

The claims are patentable for several reasons. The primary reason is that the cited combination of 
documents and the arguments related to the cited combination fail to establish a prima facie case 
of obviousness in a number of ways for every rejected claim as detailed below. 

Reason #1 - The first reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 44, claim 45, claim 46, claim 47, claim 48, 
claim 49, claim 50, claim 51 and/or claim 52 is that the cited combination does not teach or suggest 
one or more of the limitations for every rejected claim. MPEP 2143.03 provides that: to establish 
prima facie obviousness of a claimed invention, all the claim limitations must be taught or 
suggested by the prior art (In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974)). Limitations 
not taught or suggested by the cited combination include: 

1) Claim 44 (affects all of the claims under this issue, affects claims 45, 47, 51 and 52 directly). 
Limitations not taught or suggested include: 

a) using a series of models to identify one or more attributes for each of one or more elements of 
value that contribute to one or more components of value, 

b) creating a summary of the attributes for each element of value, 

c) developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, 

d) aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

e) predicting an impact of a change to one or more elements of value on enterprise cash flow, 

f) identifying a set of changes to one or more elements of value that will optimize enterprise cash 
flow, 

g) removing data associated with enterprise growth options, and 

h) using a series of models. 

As detailed below, Everest and Lyons both teach and rely on the use of a plurality of user- 
schemas. Lyons also teaches away from the claimed analysis and modeling in a number of ways 
as detailed under reason #2. 

2) Claim 46 (also affects claim 48 directly). Limitations not taught or suggested include a change 
in capital. 
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3) Claim 47. Limitations not taught or suggested include elements of value selected from the 
group consisting of brands, customers, employees, strategic partnerships and vendor 
relationships. It is well known to those of average skill in the art that the balance sheets 
manipulated by Lyons do not include the elements of value listed above. Everest has no relevant 
teachings. 

4) Claim 52. Limitations not taught or suggested include a common network schema. 

Reason # 2 - The second reason that claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, 
claim 50, claim 51 and/or claim 52 are patentable is that the cited combination fails to establish a 
prima facie case of obviousness because it teaches away from a number of claimed methods. 
MPEP § 2141.02 states that: "in determining the difference between the prior art and the claims, 
the question under 35 U.S.C. 103 is not whether the differences themselves would have been 
obvious but whether the claimed invention as a whole would have been obvious (Stratoflex, Inc. v. 
Aeroquip Corp., 713 F.2d 1530, 218 USPQ 871 (Fed. Cir. 1983))." Furthermore, it is well 
established that: A prior art reference must be considered in its entirety, i.e., as a whole, including 
portions that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, 
Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert, denied, 469 U.S. 851 (1984). Examples 
of the cited combination teaching away from the claimed invention include: 

1) The claimed invention teaches the use of a series of models to identify: attributes for use in 
element of value modeling and a net contribution to cash flow for each element of value (see 
claim 44). Lyons teaches away from this approach in several ways: 

a) by teaching that the user - not a model or series of models - is responsible for identifying the 
relationships between the data being analyzed (Lyons, C27, L25 - 38); 

b) by limiting data storage after external processing to data that appears in a report format 
(Lyons, C2, L46 - 50); 

c) by limiting other programs to processing financial schedule data stored in the datastore (Lyons 
C20, L62-C21, L2); and 

d) by storing data in an unconventional manner that is designed to support spreadsheets and four 
dimensional data analysis (Lyons, C1, L 20 - C2, L 66). 

2) The claimed invention relies on the aggregation of data from a plurality of database 
management systems (see claim 44). Everest teaches away by relying on the use of a single, 
centrally controlled, database management system for an entire enterprise (Everest, page 37 see 
page 43, Evidence Appendix) "a shared database environment requires central control to 
coordinate the collection and use of data and to integrate the storage of data; 

3) The claimed invention teaches the development and use of a model of enterprise cash flow to 
identify a contribution and a value for elements of value such as brands, customers, employees, 
production equipment strategic partnerships and vendor relationships (see claim 44 and claim 
47). Lyons teaches away from this approach in several ways: 
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a) by teaching and relying on the use of data from balance sheets that value financial assets and 
tangible elements of value such as production equipment on a historical cost basis (a fact well 
known to those of average skill in the art); and 

b) by teaching and relying on the use of a balance sheet that does not include brands, customers, 
employees, strategic partnerships and vendor relationships (a fact well known to those of average 
skill in the art). 

4) The claimed invention teaches the use of a common schema (see claim 44). Everest and 
Lyons both teach and rely on the use of a plurality of user schemas. The userschema may use 
different data names, reflect a different data structure and refer to only portions of the 
database. . . . The userschema is the fundamental component of a DBMS architecture for achieving 
sharability and evolvability (page 44, Evidence Appendix and Lyons C7, L 62 - C8, L55); 

5) The claimed invention teaches the development and use of a model of enterprise cash flow by 
component of value and element of value (see claim 44 and claim 47). Lyons teaches away by 
teaching and relying on the use of a traditional cash flow statement that teach that the elements 
of value are not the source of cash flow (a fact well known to those of average skill in the art). 

Reason # 3 - The third reason claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, 
claim 51 and/or claim 52 are patentable is that the combination of teachings described in the cited 
combination would force a change the principle of operation of at least one of the inventions 
described in the cited documents. MPEP 2143.01 provides that when "the proposed modification 
or combination of the prior art would change the principle of operation of the prior art invention 
being modified, then the teachings of the references are not sufficient to render the claims prima 
facie obvious. In re Ratti, 270 F.2d 810, 123 USPQ 349 (CCPA 1959)". The Lyons invention was 
developed to allow end users to complete four dimensional analyses of financial data. The Lyons 
specification clearly states that the unconventional data storage methods it uses is the one of the 
principles of operation that enables this type of analysis . Unlike conventional data base 
management systems or worksheet applications, the Lyons invention allows for a four dimensional 
analysis of all financial data. In particular, the data stored in the system is organized into four 
business classifications or dimensions, namely Schedule, Entity, Period and Type (SEPT) (Lyons 
C4, L 17 - 23). This unconventional data storage method creates massive redundancy that 
provides some end-user benefits. Furthermore, the data input and output functions of the Lyons 
invention rely on these data storage principles to complete their defined functions. This method of 
data storage and retrieval is also particularly well suited to filling the cells in spreadsheets - one of 
the primary uses of the Lyons invention (Lyons, C1, L 20 - C2, L 66). By way of contrast, one of 
the principles of operation for the database management systems described by Everest is a 
reliance on a conventional data storage structure that can be used to manage data with minimal 
redundancy. Everest listed the data structures used for conventional data storage in a taxonomy 
(Everest page 121, see page 46, Evidence Appendix). 
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If the Lyons invention were modified to the incorporate the conventional data storage principle of 
operation taught by Everest, then a principle of operation of the Lyons invention would be changed. 
Alternatively, if the database management systems of Everest were modified to utilize the 
unconventional data storage principle of operation taught by Lyons, then a principle of operation of 
the Everest database management systems would be changed. Because the cited combination 
requires a change in a principle of operation of at least one of the cited inventions, the teachings of 
the documents are not sufficient to render the claims prima facie obvious. 

Reason #4 - The fourth reason claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, 
claim 51 and/or claim 52 are patentable is that the Examiner has not been able to explain the 
rationale for combining the Everest and Lyons teachings to replicate the functionality of the claimed 
invention. The Supreme Court in KSR noted that the analysis supporting a rejection under 35 
U.S.C. 103 should be made explicit. The Court quoting In re Kahn 41 stated that '"[Rejections on 
obviousness cannot be sustained by mere conclusory statements; instead, there must be some 
articulated reasoning with some rational underpinning to support the legal conclusion of 
obviousness (KSR, 550 U.S. at I, 82 USPQ2d at 1396)."' In particular, the Examiner has not 
explained why the conventional database management systems taught by Everest should be 
combined with the Lyons invention. The Lyons specification clearly states that conventional 
database management systems do not support the four dimensional data analyses that the Lyons 
system was created to produce (Lyons C4, L 17-23) . 

Reason #5 - The fifth reason claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, 
claim 51 and/or claim 52 are patentable is Reason #3 listed under issue #2. 

Reason #6 - The sixth reason claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 50, 
claim 51 and/or claim 52 are patentable is Reason #4 listed under issue #2. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. This failure 
provides additional evidence that the claimed invention for producing concrete, tangible and useful 
results is new, novel and non-obvious. 

Reason #7 - The seventh reason claim 44, claim 45, claim 46, claim 47, claim 48, claim 49, claim 
50, claim 51 and claim 52 are patentable is that the claim rejections fail under both standards of the 
APA and are therefore moot. The claim rejections would fail under the substantial evidence 
standard because a prima facie case supporting claim rejection has not been presented (as noted 
above under reasons #1-6 above). The claim rejections would fail under the arbitrary and 
capricious standard of the APA because the U.S.P.T.O. has previously found the discovery of 
indicators, which are a similar to attributes, for a customer element of value to be novel, non- 
obvious (see U.S. Patent 7,092,920). Unfortunately, this is not the first instance of arbitrary and 
capricious claim rejection. 
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Issue 2 - Whether claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 and/or claim 59 
are patentable under 35 USC 103(a) over Lyons with consideration to Everest? 

The claims are patentable for several reasons. The primary reason is that the cited combination 
and the arguments related to the cited combination fail to establish a prima facie case of 
obviousness in a number of ways for every rejected claim as detailed below. 

Reason #1 - The first reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 53, claim 54, claim 55, claim 56, claim 57, 
claim 58 and/or claim 59 is that the cited combination does not teach or suggest one or more of the 
limitations for every rejected claim. MPEP 2143.03 provides that: to establish prima facie 
obviousness of a claimed invention, all the claim limitations must be taught or suggested by the 
prior art (In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974)). Limitations not taught or 
suggested by the cited combination include: 

1) Claim 53 (affects all of the claims under this issue, affects claims 54, 56, 57, 58 and 59 
directly). Limitations not taught or suggested include: 

a) using a series of models to identify one or more attributes for each of one or more elements of 
value that contribute to one or more components of value, 

b) creating a summary of the attributes for each element of value, 

c) developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, 

d) aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

e) predicting an impact of a change to one or more elements of value on enterprise cash flow, 

f) identifying a set of changes to one or more elements of value that will optimize enterprise cash 
flow, 

g) a network model of actual and forecast cash flow, 

h) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, 

i) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, with each subset being processed by a genetic algorithm independently 
of the others, 

j) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, with each subset being processed by a genetic algorithm independently 
of the others where a selective crossover produces a chromosome exchange between the 
subsets, and 

k) where the selective crossover occurs between two or more successive generations 
I) removing data associated with enterprise growth options, and 
m) using a series of models. 
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As detailed below, Everest and Lyons both teach and rely on the use of a plurality of user- 
schemas. Lyons also teaches away from the claimed analysis and modeling in a number of ways 
as detailed under reason #2. 

2) Claim 55. Limitations not taught or suggested include elements of value selected from the 
group consisting of brands, customers, employees, strategic partnerships and vendor 
relationships. It is well known to those of average skill in the art that the balance sheets 
manipulated by Lyons do not include the elements of value listed above. Everest has no relevant 
teachings. 

3) Claim 56. Limitations not taught or suggested include forecast event data and historical event 
data. 

4) Claim 59. Limitations not taught or suggested include a common network schema. 

Reason #2 - The second reason that claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 
and/or claim 59 are patentable is Reason #2 under issue #1 . 

Reason #3 - The third reason claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 and/or 
claim 59 are patentable is that the proposed combination would destroy the ability of the inventions 
described by the cited documents to function. It is well established that: when a modification of a 
reference destroys the intent, purpose or function of an invention such a proposed modification is 
not proper and the prima facie cause of obviousness cannot be properly made (In re Gordon 733 
F.2d 900, 221 U.S.PQ 1125 Fed Circuit 1984). The Everest document teaches conventional 
database management systems . These conventional database management systems rely on 
logical data structures that enable enterprise wide data management with minimal redundancy. 
Everest lists the data structures used for conventional data storage in a taxonomy (page 46, 
Evidence Appendix). The key function of the Lyons invention is the four dimensional analysis of 
financial schedule data. The Lyons specification clearly states that the unconventional data 
storage method it uses is the key to enabling this type of analysis . Unlike conventional database 
management systems or worksheet applications, the Lyons invention allows for a four dimensional 
analysis of all financial data. In particular, the data stored in the system is organized into four 
business classifications or dimensions, namely Schedule, Entity, Period and Type (SEPT) (Lyons 
C4, L 17 - 23). This data storage method creates massive redundancy that provides some end- 
user benefits. Data is read from the datastore by various report and spreadsheet generating 
functions which convert data associated with particular SEPT values to desired output formats 
(Lyons, C2, L 58 - 61). Modifying the Lyons invention to use the conventional database 
management systems taught by Everest would destroy the ability of the report and spreadsheet 
generating functions to support a four dimensional analysis. In a similar manner, modifying the 
Everest database management systems to use the unconventional Lyons method for data storage 
would destroy the ability of the Everest database management systems to support the enterprise 
wide management of all types of data without creating massive redundancy. Because the cited 
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combination would destroy the ability of at least one of the cited inventions to function, the 
teachings of the documents are not sufficient to render the claims prima facie obvious . 

Reason #4 - The fourth reason claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 and/or 
claim 59 are patentable is that the cited combination would require a change in one or more 
principles of operation of at least one of the inventions described in the cited documents. MPEP 
2143.01 provides that when "the proposed modification or combination of the prior art would 
change the principle of operation of the prior art invention being modified, then the teachings of the 
references are not sufficient to render the claims prima facie obvious. In re Ratti, 270 F.2d 810, 
123 USPQ 349 (CCPA 1959)". Changes in principle that would be required include a change in 
end-user control principle. Consistent with its function of using four-dimensional financial data 
analysis to enable users to create reports, end-user control is one of the principles of operation of 
the Lyons invention . This principle dictated the development of a software package that includes 
features such as: 

a) User-controlled data dictionaries. Each data dictionary in the Lyons invention has the 
simplest possible function - it defines one type of data (Lyons, C7, L 62 - C8, L55). Lyons 
teaches that five (5) of these separate, simple, user-controlled data dictionaries are required for 
system operation (along with one optional data dictionary); 

b) High levels of data redundancy. The SEPT values defined by the user (see a above) are 
used to identify each piece of data that will be stored and processed by the Lyons invention 
(Lyons, C2, L 35 - 50, C4, L 20 - 43). As described in the Lyons specification, this method of 
data storage provides end user benefits but it also creates a massive redundancy in data 
storage; and 

c) \Jser-controlled data management. Consistent with its goal of providing user defined 
capabilities for creating reports, the Lyons invention provides each user with a number of 
functions for flexibly defining and managing the way stored data are organized. 

At the same time, the conventional database management systems described by Everest are 
designed to support hundreds of input screens, reports and files and thousands of data items. 
Because of this, the Everest system emphasizes comprehensive, centralized control in order to 
maximize efficiency and stability. Everest specifically states that: "a shared database environment 
requires central control to coordinate the collection and use of data" (see page 43, Evidence 
Appendix). If the Lyons invention were modified to the incorporate centralized control principle 
taught by Everest, then the end-user control principle of operation of the Lyons invention would be 
changed. Alternatively, if the database management system of Everest were modified to utilize the 
end-user control principle of data management taught by Lyons, then the central control principle 
of operation of the Everest database management system would be changed. Because the cited 
combination requires a changes the principle of operation of at least one of the cited inventions, 
the teachings of the documents are not sufficient to render the claims prima facie obvious . 
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Reason #5 - The fifth reason claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 and/or claim 
59 are patentable is Reason #3 listed under issue #1 . 

Reason #6 - The sixth reason claim 53, claim 54, claim 55, claim 56, claim 57, claim 58 and/or 
claim 59 are patentable is Reason #4 listed under issue #1. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. Taken 
together, these failures provide additional evidence that the claimed invention for producing 
concrete, tangible and useful results is new, novel and non-obvious. The Appellant respectfully 
submits that the claims are also patentable for the Reason #7 listed under issue #1 . 

Issue 3 - Whether claim 65 and claim 66 are patentable under 35 USC 103(a) over Lyons with 
consideration to Everest? 

The claims are patentable for several reasons. One of the primary reasons is that the cited 
combination and the arguments related to the cited combination fail to establish a prima facie case 
of obviousness in a number of ways for every rejected claim. 

Reason #1 - The first reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 65 and/or claim 66 is that the cited 
combination does not teach or suggest one or more of the limitations for every rejected claim. 
MPEP 2143.03 provides that: to establish prima facie obviousness of a claimed invention, all the 
claim limitations must be taught or suggested by the prior art (In re Royka, 490 F.2d 981, 180 
USPQ 580 (CCPA 1974)). Claims with limitations not taught or suggested by the cited combination 
include: 

1) Claim 65 (also affects claim 66 directly). Limitations not taught or suggested include: 

a) using neural network models to identify one or more performance indicators for each of one or 
more elements of value, 

b) identifying one or more value drivers from said indicators, 

c) identifying one or more value drivers from said indicators and defining a contribution summary 
for each element of value for each component of value using said value drivers, 

d) creating a model of current operation financial performance by element and component of 
value using said contribution summaries, and 

e) simulating a current operation financial performance using said model as required to identify 
changes by element of value that will optimize one or more aspects of current operation financial 
performance 

f) automatically aggregating enterprise related event data from a plurality of database 
management systems into files or tables in a common database, and 

g) converting the data into a format that supports a common schema for analyzing and modeling 
an enterprise. 
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2) Claim 66. Limitations and activities not taught or suggested include: 

a) using a common data dictionary to identify a common set of attributes in the enterprise related 
data from the plurality of database management systems, and 

b) identifying common attributes and automatically integrating data from a plurality of database 
management systems. 

Reason # 2 - The second reason that claim 65 and/or claim 66 are patentable is because the cited 
combination fails to establish a prima facie case of obviousness because it teaches away from a 
number of claimed methods. MPEP § 2141.02 states that: "in determining the difference between 
the prior art and the claims, the question under 35 U.S.C. 103 is not whether the differences 
themselves would have been obvious but whether the claimed invention as a whole would have 
been obvious (Stratoflex, Inc. v. Aeroquip Corp., 713 F.2d 1530, 218 USPQ 871 (Fed. Cir. 1983))." 
Furthermore, it is well established that: A prior art reference must be considered in its entirety, i.e., 
as a whole, including portions that would lead away from the claimed invention. W.L. Gore & 
Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert, denied, 469 
U.S. 851 (1984). Examples of the cited combination teaching away from the claimed invention 
include: 

1) The claimed invention teaches the use of a common schema (see claim 44). Everest and 
Lyons both teach and rely on the use of a plurality of user schemas. The userschema may use 
different data names, reflect a different data structure and refer to only portions of the 
database. . . . The userschema is the fundamental component of a DBMS architecture for achieving 
sharability and evolvability (page 44, Evidence Appendix and Lyons C7, L 62 - C8, L55); 

2) The claimed invention teaches the use of neural network models to identify: indicators for use 
in element of value modeling and a net contribution to current operation value for each element of 
value (see claim 65). Lyons teaches away from this approach in several ways: 

a) by teaching that the user - not a model or series of models - is responsible for identifying the 
relationships between the data being analyzed (Lyons, C27, L25 - 38); 

b) by limiting data storage after external processing to data that appears in a report format 
(Lyons, C2, L46 - 50); 

c) by limiting other programs to processing financial schedule data stored in the datastore (Lyons 
C20, L62-C21, L2); and 

d) by storing data in an unconventional manner that is designed to support spreadsheets and four 
dimensional data analysis (Lyons, C1, L 20 - C2, L 66). 

3) The claimed invention relies on the aggregation of data from a plurality of database 
management systems (see claim 65). Everest teaches away by relying on the use of a single, 
centrally controlled, database management system for an entire enterprise (Everest, page 37, 
see page 43, Evidence Appendix) "a shared database environment requires central control to 
coordinate the collection and use of data and to integrate the storage of data"; 
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4) The claimed invention teaches the conventional storage of data in files or tables (see claim 65 
and 66). Lyons teaches away by teaching and relying on an unconventional data storage method 
where all data associated with a particular Schedule, Entity, Period and Type (SEPT) are 
identified by a SEPT value and all data associated with a particular SEPT value are stored in a 
predetermined pattern relative to the SEPT value in a single, central datastore (Lyons, C2, L45 - 
50). Lyons teaches that this unconventional data storage method enables the four dimensional 
analysis of data. 

5) The claimed invention teaches the development and use of a model of current operation cash 
flow by component of value and element of value (see claim 65). Lyons teaches away by 
teaching and relying on the use of a traditional cash flow statement that teach that the elements 
of value are not the source of cash flow (a fact well known to those of average skill in the art). 

6) References provided by the Appellant (Rappaport) and the U.S.P.T.O. (Bielinski) teach away 
from the method of value driver identification and use incorporated in the claimed invention in a 
number of ways (see Evidence Appendix, pages 47 - 49 for a summary). 

Reason #3 - The third reason claim 65 and claim 66 are patentable is Reason #3 listed under issue 
#1. 

Reason #4 - The fourth reason claim 65 and claim 66 are patentable is Reason #4 listed under 
issue #1. 

Reason #5 - The fifth reason claim 65 and claim 66 are patentable is Reason #3 listed under issue 
#2. 

Reason #6 - The sixth reason claim 65 and claim 66 are patentable is Reason #4 listed under 
issue #2. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. This failure 
provides additional evidence that the claimed invention for producing concrete, tangible and useful 
results is new, novel and non-obvious. 

Reason #7 - The seventh reason claim 65 and claim 66 are patentable is that the claim rejections 
fail under both standards of the APA and are therefore moot. The claim rejections would fail under 
the substantial evidence standard because a prima facie case supporting claim rejection has not 
been presented (as noted above under reasons #1-6 above). The claim rejections would fail 
under the arbitrary and capricious standard of the APA because the U.S.P.T.O. has previously 
found the discovery of indicators for a customer element of value to be novel, non-obvious (see 
U.S. Patent 7,092,920). Unfortunately, this is not the first instance of arbitrary and capricious claim 
rejection. 
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Issue 4 - Whether claim 67, claim 68, claim 69 and/or claim 70 are patentable under 35 USC 
103(a) over Lyons with consideration to Everest? 

The claims are patentable for several reasons. One of the primary reasons is that the cited 
combination and the arguments related to the cited combination fail to establish a prima facie case 
of obviousness in a number of ways for every rejected claim. 

Reason #1 - The first reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 67, claim 68, claim 69 and/or claim 70 is that 
the cited combination does not teach or suggest one or more of the limitations for every rejected 
claim. MPEP 2143.03 provides that: to establish prima facie obviousness of a claimed invention, 
all the claim limitations must be taught or suggested by the prior art (In re Royka, 490 F.2d 981, 
180 USPQ 580 (CCPA 1974)). Claims with limitations not taught or suggested by the cited 
combination include: 

1) Claim 67 (also affects claims 68, claim 69 and 70 directly). Limitations not taught or suggested 
include: 

a) using a series of models to identify one or more attributes for each of one or more elements of 
value that contribute to one or more components of value, 

b) creating a summary of the attributes for each element of value, 

c) developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, 

d) aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

e) predicting an impact of a change to one or more elements of value on enterprise cash flow, 

f) identifying a set of changes to one or more elements of value that will optimize enterprise cash 
flow, 

g) a network model of actual and forecast cash flow, 

h) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, 

i) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, with each subset being processed by a genetic algorithm independently 
of the others, 

j) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, with each subset being processed by a genetic algorithm independently 
of the others where a selective crossover produces a chromosome exchange between the 
subsets, and 

k) where the selective crossover occurs between two or more successive generations 
I) removing data associated with enterprise growth options, 
m) using a series of models, 

n) identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 
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0) converting said data source data to a common schema by using said relationships in an 
application software segment, 

p) storing said converted event data in an application database for use in processing, 

q) forecast an impact of a response to one or more events from the plurality of events, and 

r) identify an optimal response to one or more events from the plurality of events 

2) Claim 68. Limitations not taught or suggested include a common schema that is defined by an 
application database schema. 

3) Claim 69. Limitations not taught or suggested include a common schema that further 
comprises a network schema. 

Reason # 2 - The second reason that claim 67, claim 68, claim 69 and/or claim 70 are patentable is 
because the cited combination fails to establish a prima facie case of obviousness because it 
teaches away from a number of claimed methods. MPEP § 2141.02 states that: "in determining 
the difference between the prior art and the claims, the question under 35 U.S.C. 103 is not 
whether the differences themselves would have been obvious but whether the claimed invention as 
a whole would have been obvious (Stratoflex, Inc. v. Aeroquip Corp., 713 F.2d 1530, 218 USPQ 
871 (Fed. Cir. 1983))." Furthermore, it is well established that: A prior art reference must be 
considered in its entirety, i.e., as a whole, including portions that would lead away from the claimed 
invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 
1983), cert, denied, 469 U.S. 851 (1984). Examples of the cited combination teaching away from 
the claimed invention include: 

1) The claimed invention teaches the use of an application software segment to convert data (see 
claim 67). Everest teaches that the conversion of data is a database function (Everest page 409, 
see page 45, Evidence Appendix) "it is highly desirable for data conversion to be performed by 
the same underlying modules in the database control system"; 

2) The claimed invention teaches the use of a series of models to identify: attributes for use in 
element of value modeling and a net contribution to cash flow for each element of value (see 
claim 53/67). Lyons teaches away from this approach in several ways: 

a) by teaching that the user - not a model or series of models - is responsible for identifying the 
relationships between the data being analyzed (Lyons, C27, L25 - 38); 

b) by limiting data storage after external processing to data that appears in a report format 
(Lyons, C2, L46 - 50); 

c) by limiting other programs to processing financial schedule data stored in the datastore (Lyons 
C20, L62-C21, L2); and 

d) by storing data in an unconventional manner that is designed to support four dimensional data 
analysis and spreadsheets (Lyons, C1 , L 20 - C2, L 66). 

3) The claimed invention relies on the aggregation of data from a plurality of database 
management systems (see claim 53/67). Everest teaches away by relying on the use of a single, 
centrally controlled, database management system for an entire enterprise (Everest, 37 see page 
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45, Evidence Appendix) "a shared database environment requires central control to coordinate 
the collection and use of data and to integrate the storage of data"; 

4) The claimed invention teaches the use of a common schema (see claim 67). Everest and 
Lyons both teach and rely on the use of a plurality of user schemas. The userschema may use 
different data names, reflect a different data structure and refer to only portions of the 
database. . . . The userschema is the fundamental component of a DBMS architecture for achieving 
sharability and evolvability (page 44, Evidence Appendix and Lyons C7, L 62 - C8, L55); 

5) The claimed invention teaches the development and use of a model of enterprise cash flow by 
component of value and element of value. Lyons teaches away by teaching and relying on the 
use of a traditional cash flow statement that teach that the elements of value are not the source of 
cash flow (a fact well known to those of average skill in the art). 

Reason #3 - The third reason claim 67, claim 68, claim 69 and/or claim 70 are patentable is 
Reason #3 listed under issue #1. 

Reason #4 - The fourth reason claim 67, claim 68, claim 69 and/or claim 70 are patentable is 
Reason #4 listed under issue #1. 

Reason #5 - The fifth reason claim 67, claim 68, claim 69 and/or claim 70 are patentable is Reason 
#3 listed under issue #2. 

Reason #6 - The sixth reason claim 67, claim 68, claim 69 and/or claim 70 are patentable is 
Reason #4 listed under issue #2. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. Taken 
together, these failures provide additional evidence that the claimed invention for producing 
concrete, tangible and useful results is new, novel and non-obvious. The Appellant respectfully 
submits that the claims are also patentable for the Reason #7 listed under issue #1 . 

Issue 5 - Whether claim 71, claim 72, claim 73, claim 74, claim 75 and claim 76 are 
patentable over Lyons with consideration to Everest? 

The claims are patentable for several reasons. One of the primary reasons is that the cited 
combination and the arguments related to the cited combination fail to establish a prima facie case 
of obviousness in a number of ways for every rejected claim. 

Reason #1 - The first reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 71, claim 72, claim 73, claim 74, claim 75 
and/or claim 76 is that the cited combination does not teach or suggest one or more of the 
limitations for every rejected claim. MPEP 2143.03 provides that: to establish prima facie 
obviousness of a claimed invention, all the claim limitations must be taught or suggested by the 
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prior art (In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974)). Claims with limitations not 
taught or suggested by the cited combination include: 

1) Claim 71 (affects claims 72, claim 73, claim 74, claim 75 and 76 directly). Limitations not taught 
or suggested include: 

a) analyzing data with a series of models to identify one or more attributes for each of one or 
more elements of value that impact one or more components of value and a value of the element 
of value 

b) analyzing data with a series of models to identify one or more attributes for each of one or 
more elements of value that impact one or more components of value and a value of the element 
of value and create a summary of said attributes, 

c) developing a model of an actual and a forecast enterprise cash flow by a component of value 
and element of value using said summaries, 

d) using the model to calculate a current operation value contribution for each of one or more 
elements of value, 

e) obtaining a plurality of data dictionaries and event data from a plurality of data sources via a 
network connection, 

f) identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

g) converting said data source data to a common schema by using said relationships in an 
application software segment, 

h) storing said converted event data in an application database for use in processing, 

i) predicting an impact of a change to one or more elements of value on enterprise cash flow, 

j) identifying a set of changes to one or more elements of value that will optimize enterprise cash 
flow, 

k) elements of value selected from the group consisting of brands, customers, employees, 
partnerships, vendor relationships and combinations thereof, 

1) modeling cash flow only after removing data associated with all enterprise growth options, and 
m) where the cash flow for each element of value by a component of value comprises a net cash 
flow comprised of an element of value contribution to each component of value net of its impact 
on one or more other elements of value. 

2) Claim 74. Limitations not taught or suggested include database management systems that are 
obtained from the group consisting of operation management systems, sales management 
systems, human resource systems, accounts receivable systems, accounts payable systems, 
capital asset systems, inventory systems, invoicing systems, payroll systems, purchasing 
systems, an Intranet and combinations thereof. Everest teaches the use of a single database 
management system and does not mention an Intranet. Lyons teaches the use of data from 
systems that produce financial schedules (basic and advanced financial systems) and does not 
mention an Intranet. 
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3) Claim 75. Limitations not taught or suggested include elements of value and components of 
value. 

4) Claim 76. Limitations not taught or suggested include the automated conversion of data. 

Reason # 2 - The second reason that claim 71, claim 72, claim 73, claim 74, claim 75 and/or claim 
76 are patentable is because the cited combination fails to establish a prima facie case of 
obviousness because it teaches away from a number of claimed methods. MPEP § 2141.02 
states that: "in determining the difference between the prior art and the claims, the question under 
35 U.S.C. 103 is not whether the differences themselves would have been obvious but whether the 
claimed invention as a whole would have been obvious (Stratoflex, Inc. v. Aeroquip Corp., 713 
F.2d 1530, 218 USPQ 871 (Fed. Cir. 1983))." Furthermore, it is well established that: A prior art 
reference must be considered in its entirety, i.e., as a whole, including portions that would lead 
away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 
USPQ 303 (Fed. Cir. 1983), cert, denied, 469 U.S. 851 (1984). Examples of the cited combination 
teaching away from the claimed invention include: 

1) The claimed invention teaches the use of an application software segment to convert data (see 
claim 71). Everest teaches that the conversion of data is a database function (see page 45, 
Evidence Appendix) "it is highly desirable for data conversion to be performed by the same 
underlying modules in the database control system"; 

2) The claimed invention teaches the use of a series of models to identify: attributes for use in 
element of value modeling and a net contribution to cash flow for each element of value (see 
claim 44). Lyons teaches away from this approach in several ways: 

a) by teaching that the user - not a model or series of models - is responsible for identifying the 
relationships between the data being analyzed (Lyons, C27, L25 - 38); 

b) by limiting data storage after external processing to data that appears in a report format 
(Lyons, C2, L46 - 50); 

c) by limiting other programs to processing financial schedule data stored in the datastore (Lyons 
C20, L62-C21, L2); and 

d) by storing data in an unconventional manner that is designed to support spreadsheets and four 
dimensional data analysis (Lyons, C1, L 20 - C2, L 66). 

3) The claimed invention relies on the aggregation of data from a plurality of database 
management systems (see claim 44). Everest teaches away by relying on the use of a single, 
centrally controlled, database management system for an entire enterprise (Everest, page 37, 
see page 43, Evidence Appendix "a shared database environment requires central control to 
coordinate the collection and use of data and to integrate the storage of data') ; 

4) The claimed invention teaches the development and use of a model of enterprise cash flow to 
identify a contribution and a value for elements of value such as brands, customers, employees, 
production equipment strategic partnerships and vendor relationships (see claim 44 and claim 
47). Lyons teaches away from this approach in several ways: 
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a) by teaching and relying on the use of data from balance sheets that value financial assets and 
tangible elements of value such as production equipment on a historical cost basis (a fact well 
known to those of average skill in the art); and 

b) by teaching and relying on the use of a balance sheet that does not include brands, customers, 
employees, strategic partnerships and vendor relationships (a fact well known to those of average 
skill in the art). 

5) The claimed invention teaches the use of a common schema (see claim 44). Everest and 
Lyons both teach and rely on the use of a plurality of user schemas. The userschema may use 
different data names, reflect a different data structure and refer to only portions of the 
database. . . . The userschema is the fundamental component of a DBMS architecture for achieving 
sharability and evolvability (page 44, Evidence Appendix and Lyons C7, L 62 - C8, L55); 

6) The claimed invention teaches the development and use of a model of enterprise cash flow by 
component of value and element of value where the elements of value are brands, customers, 
employees, strategic partnerships and vendor relationships (see claim 44 and claim 47). Lyons 
teaches away by teaching and relying on the use of a traditional cash flow statement that teach 
that the elements of value are not the source of cash flow (a fact well known to those of average 
skill in the art). 

Reason #3 - The third reason claim 71, claim 72, claim 73, claim 74, claim 75 and/or claim 76 are 
patentable is Reason #3 listed under issue #1 . 

Reason #4 - The fourth reason claim 71, claim 72, claim 73, claim 74, claim 75 and/or claim 76 are 
patentable is Reason #4 listed under issue #1 . 

Reason #5 - The fifth reason claim 71, claim 72, claim 73, claim 74, claim 75 and/or claim 76 are 
patentable is Reason #3 listed under issue #2. 

Reason #6 - The sixth reason claim 71, claim 72, claim 73, claim 74, claim 75 and/or claim 76 are 
patentable is Reason #4 listed under issue #2. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. Taken 
together, these failures provide additional evidence that the claimed invention for producing 
concrete, tangible and useful results is new, novel and non-obvious. The Appellant respectfully 
submits that the claims are also patentable for the Reason #7 listed under issue #1 . 

Issue 6 - Whether claim 77, claim 78, claim 79, claim 80 and claim 81 are patentable over 
Lyons with consideration to Everest? 

The claims are patentable for several reasons. One of the primary reasons is that the cited 
combination and the arguments related to the cited combination fail to establish a prima facie case 
of obviousness in a number of ways for every rejected claim. 
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Reason #1 - The first reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 77, claim 78, claim 79, claim 80 and/or claim 
81 is that the cited combination does not teach or suggest one or more of the limitations for every 
rejected claim. MPEP 2143.03 provides that: to establish prima facie obviousness of a claimed 
invention, all the claim limitations must be taught or suggested by the prior art (In re Royka, 490 
F.2d 981, 180 USPQ 580 (CCPA 1974)). Claims with limitations not taught or suggested by the 
cited combination include: 

1) Claim 77 (also affects claims 78, claim 79, claim 80 and claim 81 directly). Limitations not 
taught or suggested include: 

a) analyzing data with a series of models to identify one or more attributes for each of one or 
more elements of value that impact one or more components of value and a value of the element 
of value, 

b) analyzing data with a series of models to identify one or more attributes for each of one or 
more elements of value that impact one or more components of value and a value of the element 
of value and create a summary of said attributes, 

c) developing a model of an actual and a forecast enterprise cash flow by a component of value 
and element of value using said summaries, 

d) using the model to calculate a current operation value contribution for each of one or more 
elements of value, 

e) obtaining a plurality of data dictionaries and event data from a plurality of data sources via a 
network connection, 

f) identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

g) converting said data source data to a common schema by using said relationships in an 
application software segment, 

h) storing said converted event data in an application database for use in processing, 

i) modeling financial performance only after removing data associated with all enterprise growth 
options, 

j) a common network schema, 
k) a series of models, 

1) a plurality of data sources that comprise database management systems for a plurality of 
enterprise transaction systems, and 

m) identifying one or more changes by element of value that will optimize one or more aspects of 
current operation financial performance. 

2) Claim 78. Limitations not taught or suggested include a back-end interface that comprises a 
network connection. Everest teaches the use of a separate computer for a back-end interface. 

3) Claim 79. Limitations not taught or suggested include accessing, converting, integrating and 
storing data from an Internet. 
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4) Claim 80. Limitations not taught or suggested include elements of value and components of 
value. 

5) Claim 81. Limitations not taught or suggested include database management systems that are 
obtained from the group consisting of operation management systems, sales management 
systems, human resource systems, accounts receivable systems, accounts payable systems, 
capital asset systems, inventory systems, invoicing systems, payroll systems, purchasing 
systems, an Intranet and combinations thereof. Everest teaches the use of a single database 
management system and does not mention an Intranet. Lyons teaches the use of data from 
systems that produce financial schedules (basic and advanced financial systems) and does not 
mention an Intranet. 

Reason # 2 - The second reason that claim 77, claim 78, claim 79, claim 80 and/or claim 81 are 
patentable is Reason # 2 listed under issue #5. 

Reason #3 - The third reason claim 77, claim 78, claim 79, claim 80 and/or claim 81 are patentable 
is Reason #3 listed under issue #1. 

Reason #4 - The fourth reason claim 77, claim 78, claim 79, claim 80 and/or claim 81 are 
patentable is Reason #4 listed under issue #1 . 

Reason #5 - The fifth reason claim 77, claim 78, claim 79, claim 80 and/or claim 81 are patentable 
is Reason #3 listed under issue #2. 

Reason #6 - The sixth reason claim 77, claim 78, claim 79, claim 80 and/or claim 81 are patentable 
is Reason #4 listed under issue #2. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. Taken 
together, these failures provide additional evidence that the claimed invention for producing 
concrete, tangible and useful results is new, novel and non-obvious. The Appellant respectfully 
submits that the claims are also patentable for the Reason #7 listed under issue #1 . 
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Conclusion 

As detailed above, the evidence used to support the art rejections of the pending claims consists of 
a document combination that fails to support an obviousness rejection for a single claim. For this 
reasons and the reasons listed below, the Appellant respectfully but forcefully contends that each 
claim is patentable. 

The Appellant notes that with respect to the prosecution of the instant application, it appears that 
the U.S.P.T.O. has not fully complied with the requirements set forth in the APA and 35 USC 3. 
Among other things, the Appellant specifically notes that: 

a) There appears to have been numerous instances of non-compliance with MPEP 904.03; 

b) The prosecution of the instant application has been substantially delayed for a variety of 
reasons. At least part of the delay appears to have occurred because the Examiner refused to 
respond to reasonable requests for a copy of a missing office action; and 

c) The prior art review for the instant application appears to have been completed under a different 
standard than that used for the review and allowance of other, similar applications. 

Therefore, reversal of all rejections is courteously solicited. 

Respectfully submitted, 

/B.J. Bennett/ 

B.J. Bennett, President, Asset Trust, Inc. 
Dated: February 3, 2008 
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Claims Appendix 



44. A program storage device readable by a computer, tangibly embodying a program of 
instructions executable by at least one computer to perform a data method, the method 
comprising: 

aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

storing said aggregated data in one or more tables or files to support processing, 
analyzing at least a portion of said data with a series of models to identify one or more attributes 
for each of one or more elements of value that contribute to one or more components of value 
and create a summary of said attributes for each element of value, 

developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, and 
using the model to calculate a current operation value contribution for each of one or more 
elements of value and complete tasks selected from the group consisting of predicting an impact 
of a change to one or more elements of value on enterprise cash flow and identifying a set of 
changes to one or more elements of value that will optimize enterprise cash flow, produce 
financial statements that identify value and value changes by element of value and combinations 
thereof 

where the current operation value of each of one or more elements of value is reported in an 
enterprise balance sheet, 

where the enterprise cash flow is modeled only after removing data associated with all 
enterprise growth options, and 

where the predictive model is a model of actual and forecast cash flow. 

45. The program storage device of claim 44 wherein the enterprise related data are aggregated in 
accordance with a common data dictionary that identifies a common set of attributes selected from 
the group consisting of: category of value, component of value, element of value, currency, unit of 
measure and combinations thereof. 

46. The program storage device of claim 45, wherein the components of value are selected from 
the group consisting of revenue, expense, change in capital and combinations thereof. 

47. The program storage device of claim 44, wherein the elements of value are selected from the 
group consisting of brands, customers, employees, production equipment, strategic partnerships, 
vendor relationships and combinations thereof. 

48. The program storage device of claim 46, wherein at least part of enterprise-related data is 
entered for each point of time over a sequential series of points in time preceding a specified 
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valuation date. 

49. The program storage device of claim 48, wherein the enterprise related data further comprise 
forecast event data and historical event data. 

50. The program storage device of claim 49, wherein the enterprise related data further comprises 
transaction data. 

51. The program storage device of claim 44 wherein said plurality of database management 
systems are obtained from the group consisting of advanced financial systems, basic financial 
systems, operation management systems, sales management systems, human resource systems, 
accounts receivable systems, accounts payable systems, capital asset systems, inventory 
systems, invoicing systems, payroll systems, purchasing systems, the Internet and combinations 
thereof. 

52. The program storage device of claim 44, wherein the common schema further comprises a 
network model. 

53. A computer-implemented method, comprising: 

aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

storing said aggregated data in one or more tables or files to support processing for enterprise 
analysis and modeling, 

analyzing at least a portion of said data with a series of models to identify one or more attributes 
for each of one or more elements of value that contribute to a value of the element of value and 
create a summary of said attributes, 

developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, 
using the model to calculate a current operation value contribution for each of one or more 
elements of value, and 

preparing and presenting an enterprise financial statement that includes a current operation value 

for each of one or more elements of value 
where the one or more elements of value comprise one or more intangible elements of value, 
where the one or more attributes for each of one or more elements of value further comprise 
one or more value drivers, 

where the enterprise cash flow is modeled only after removing data associated with all 
enterprise growth options, and 

where the predictive model is a network model of actual and forecast cash flow where the data 
being analyzed is partitioned into a plurality of subsets, with each subset being processed by a 
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genetic algorithm independently of the others and where a selective crossover produces a 
chromosome exchange between the subsets, and 

where the selective crossover occurs between two or more successive generations. 

54. The method of claim 53, wherein the enterprise related data are aggregated in accordance 
with a common data dictionary that identifies a common set of attributes selected from the group 
consisting of category of value, component of value, element of value, currency, unit of measure 
and combinations thereof. 

55. The method of claim 54, wherein one or more elements of value are selected from the group 
consisting of brands, customers, employees, production equipment, strategic partnerships, vendor 
relationships and combinations thereof. 

56. The method of claim 53, wherein enterprise related data further comprises forecast event data 
and historical event data. 

57. The method of claim 53, wherein the enterprise related data further comprises transaction 
data. 

58. The method of claim 53, wherein said plurality of database management systems are obtained 
from the group consisting of advanced financial systems, basic financial systems, operation 
management systems, sales management systems, human resource systems, accounts receivable 
systems, accounts payable systems, capital asset systems, inventory systems, invoicing systems, 
payroll systems, purchasing systems, the Internet and combinations thereof. 

59. The method of claim 53, wherein the common schema further comprises a network model. 

65. A computer-implemented method, comprising: 
automatically aggregating enterprise related event data from a plurality of database management 
systems into files or tables in a common database, thereby converting the data into a format that 
supports a common schema for analyzing and modeling an enterprise, 

using neural network models to identify one or more performance indicators for each of one or 
more elements of value, 

identifying one or more value drivers from said indicators and defining a contribution summary for 
each element of value for each component of value using said value drivers, 
creating a model of current operation financial performance by element and component of value 
using said contribution summaries, and 

simulating a current operation financial performance using said model as required to identify 
changes by element of value that will optimize one or more aspects of current operation financial 
performance 
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where the current operation financial performance is modeled only after removing data 
associated with all enterprise growth options, 

where the elements of value are selected from the group consisting of brands, customers, 
employees, intellectual capital, partners, vendors, vendor relationships and combinations 
thereof, and 

where the components of value are selected from the group consisting of revenue, expense, 
capital change and combinations thereof. 

66. The method of claim 65, the method further comprising: 

using a common data dictionary to identify a common set of attributes in the enterprise related 
data from the plurality of database management systems, the attributes including at least one 
of: component of value, currency, element of value, unit of measure, or a combination thereof; 
automatically aggregating the enterprise related data from the plurality of database 
management systems using the identified common set of attributes. 

67. A computer readable medium having sequences of instructions stored therein, which when 
executed cause the processor in at least one computer to perform an enterprise data integration 
and analysis method, comprising: 

obtaining a plurality of data dictionaries and event data from a plurality of data sources via a 
network connection, 

identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

converting said data source data to a common schema by using said relationships in an 
application software segment, 

storing said converted event data in an application database for use in processing, and 
analyzing said data using the enterprise cash flow model of claim 53 as required to forecast an 
impact of a response to one or more events from the plurality of events and optionally identify 
an optimal response to one or more events from the plurality of events 
where a plurality of data sources further comprise a plurality of database management 
systems for applications selected from the group consisting of a basic financial system, a 
human resource system, an advanced financial system, a sales system, an operations system, 
an accounts receivable system, an accounts payable system, a capital asset system, an 
inventory system, an invoicing system, a payroll system, a purchasing system and 
combinations thereof and 
where event data comprise transaction data. 

68. The computer readable medium of claim 67, wherein a common schema is defined by an 
application database schema. 
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69. The computer readable medium of claim 67, wherein a common schema further comprises a 
network schema. 

70. The computer readable medium of claim 67, wherein a common schema contains a common 
data dictionary where said common data dictionary defines common attributes selected from the 
group consisting of elements of value, components of value, currencies, units of measure, time 
periods, dates and combinations thereof. 

71. A financial system, comprising: 

a computer with a processor having circuitry to execute instructions; 

a storage device available to said processor with sequences of instructions stored therein, an 
interface coupled to a plurality of data sources each of which has a data dictionary, and an 
application software segment which when executed causes the processor to: 
obtain a plurality of data dictionaries and data from the plurality of data sources, 
identify one or more relationships between each data source data dictionary and an 
application database data dictionary, 

convert said data source data to a common schema by using said relationships, 

store said converted data in an application database for use in processing, 

analyzing at least a portion of said data with a series of models to identify one or more 

attributes for each of one or more elements of value that impact one or more components of 

value and a value of the element of value and create a summary of said attributes, 

developing a model of an actual and a forecast enterprise cash flow by a component of value 

and element of value using said summaries, and 

using the model to calculate a current operation value contribution for each of one or more 
elements of value and complete tasks selected from the group consisting of predicting an 
impact of a change to one or more elements of value on enterprise cash flow and identifying a 
set of changes to one or more elements of value that will optimize enterprise cash flow and 
combinations thereof 

where the one or more elements of value are selected from the group consisting of brands, 
customers, employees, partnerships, vendor relationships and combinations thereof, 
where the enterprise cash flow is modeled only after removing data associated with all 
enterprise growth options, and 

where the cash flow for each element of value by a component of value comprises a net 
cash flow comprised of an element of value contribution to each component of value net of 
its impact on one or more other elements of value. 

72. The system of claim 71 , wherein a plurality of data sources further comprise a plurality of 
relational databases that use different data formats. 
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73. The system of claim 71 , wherein an interface further comprises a network connection. 

74. The system of claim 71, wherein a plurality of data sources further comprise database 
management systems for applications selected from the group consisting of a basic financial 
system, a human resource system, an advanced financial system, a sales system, an operations 
system, an accounts receivable system, an accounts payable system, a capital asset system, an 
inventory system, an invoicing system, a payroll system,, a purchasing system, an intranet and 
combinations thereof. 

75. The system of claim 71, wherein a common schema contains a common data dictionary that 
defines common attributes selected from the group consisting of elements of value, components of 
value, currencies, units of measure, time periods, dates and combinations thereof. 

76. The system of claim 71, wherein a conversion of data to a common schema further comprises 
an conversion of data that is completed automatically. 

77. A computer implemented data method, comprising: 

accessing a plurality of enterprise data and data dictionaries via a back-end interface coupled to 
a plurality of data sources, 

identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

converting said enterprise data to a common schema by using said relationships in an 
application software segment, and 

storing said converted data in an application database for use in processing, 
analyzing at least a portion of said data to create a plurality of network models that identify a 
contribution for each of one or more elements of value to one or more aspects of current 
operation financial performance using said data, 

using said models to calculate a current operation value contribution for each of one or more 

elements of value and to identify one or more changes by element of value that will optimize 

one or more aspects of current operation financial performance, and 

displaying the one or more identified changes 
where the one or more aspects of financial performance are selected from the group 
consisting of revenue, expense, capital change, cash flow and combinations thereof, 
where the aspects of financial performance are modeled only after removing data associated 
with all enterprise growth options, 

where a common schema further comprises a network schema, and 

where a plurality of data sources further comprise database management systems for a 

plurality of enterprise transaction systems. 

78. The method of claim 77, wherein a back-end interface further comprises a network connection. 
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79. The method of claim 77, wherein the method further comprises accessing, converting, 
integrating and storing data from an Internet. 

80. The method of claim 77, wherein a common schema further comprises a common data 
dictionary where said common data dictionary defines common attributes selected from the group 
consisting of elements of value, components of value, currencies, units of measure, time periods, 
dates and combinations thereof. 

81. The method of claim 77, wherein a plurality of enterprise transaction systems are selected 
from the group consisting of a basic financial system, a human resource system, an advanced 
financial system, a sales system, an operations system, an accounts receivable system, an 
accounts payable system, a capital asset system, an inventory system, an invoicing system, a 
payroll system, a purchasing system, an Intranet and combinations thereof. 
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Evidence Appendix 

Pages 40 - 46 excerpt from Everest document first submitted August 1 7, 2006 

Pages 47 - 49 affidavit under Rule 1 32 first submitted November 5, 2007 

Pages 49-53 4 pages returned to file wrapper on April 8, 2006 

Pages 54 - 55 Petition-response dated August 27, 2004 

Page 56 Page from November 30, 2007 Amendment/Reply 

Page 57 Page from reference first submitted November 20, 2007 

Page 58 Page from reference first submitted November 30, 2007 
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36 Everest: database management 

An organization cannot simply acquire a DBMS, plug it in, and watch it run. A 
DBMS by itself has no data, no stored queries or report definitions, and no user 
application programs to act on that data. The organization must collect and store (or 
convert) data, must train users, and must develop report definitions and application 
processes to operate in the new database environment. 

As DBMSs become less costly, more comprehensive in capabilities, easier to use. 
and available on smaller systems (minicomputers and microcomputers), the counter- 
vailing forces diminish. In spite of the cost of a DBMS, an organization's need may be 
so overwhelming that waiting any longer would be an expensive mistake — as it be- 
comes increasingly expensive to develop new applications using obsolete tools and 
methods. 



2.4 OBJECTIVES OF DATABASE MANAGEMENT* 

Having considered the various factors which can motivate an organization to move 
toward the database approach and acquire a DBMS, what are the objectives to be 
accomplished with such a move? This section outlines the various objectives an organi- 
zation my have in moving to the database approach. 

Motivators are problems an organization faces while objectives are the desirable 
end results stemming from a solution to those problems. An expression of objectives 
serves to focus attention on the needs of the using environment and the system and 
administrative requirements for meeting those needs. Some objectives of database 
management derive directly from the assumed context of organizations and manage- 
ment information systems. 

The proper management of any resource involves making it available for its in- 
tended purpose and controlling its use so as to maintain its integrity, ensuring that it is 
used as intended and that it will be available for future use. Management implies both 
control and use. Database management encompasses the control and use of data re- 
sources in an organization. Control involves maintaining the existence and quality of 
the database and restricting its use to authorized people. Control seeks to maintain 
database integrity. Use of data resources leads to the objective of availability, which 
includes sharing present data resources and enhancing future availability. The objec- 
tives of sharability, availability, cvolvability, and integrity are related as shown in 
Figure 2-2. 

2.4.1 Sharability 

An ability to share data resources is a fundamental objective of database manage- 
ment. In its fullest interpretation, this means different people and different processes 
using the same actual data at virtually the same time. 

* An earlier version of Ihe material in this chapter appeared in Information Systems: COINS-IV, Proceed- 
ings of the Fourth International Symposium on Computer and Inlormanon Sciences, Miami Beach. Florida. 
1972 December 14-16, edited hy Julius T. Tou. New York: Plenum Press. 1974. pages 1-35. Portions 
reprinted with permission. 



Serial No.: 08/999,245 



42 



CHAPTER TWO: MOTIVATION. OBJECTIVES, AND EVOLUTION OF THE DATABASE APPROACH 37 




EVOLVABILITY 
"Future Availability" 



Figure 2-2. Objectives of Database Management. 

The management of any resource involves both the use of that resource and the control of its use. 



No person in an organization can act completely independently of everyone else in 
the organization. An organization brings together a variety of human talents to work 
together toward common goals. In working toward goals, people perform various 
operations and activities in varying degrees of cooperation or conflict. A database, 
whether or not it can be identified as a single physical entity, contains data relating to 
the primary and support operations of an organization. Sharing of data is a necessary 
first step toward a corporate database. 

Since the data pertains to various aspects of the organization, it literally "be- 
longs" to the whole organization and not to any one individual. A system which 
provides shared access to a corporate database is quite different from a typical time- 
sharing system where files are "owned" by individual users.* In organizations, shared 
files are the general rule and private files become the exception. 

A shared database environment requires central control to coordinate the collection 
and use of data and to integrate the storage of data. This can result in increased 
consistency, reduced redundancy, and reduced effort in the capture and maintenance of 
data. 

Rather far reaching ramifications stem from the stated objective of sharability: 

• Serving different types of users with varying skill levels 

• Handling different user views of the same stored data 

• Combining interrelated data 

• Setting standards 

• Controlling concurrent updates so as to maintain data integrity 

• Coordinating restart and recovery operations across multiple users 

This list indicates some of the additional problems which arise in managing shared 
data. A central implication of sharing is that compromise will often be required be- 



*The typical lime-sharing system in university or scientific research environments permits sharing lime 
on computer system resources. Time-sharing systems handle the private files of various participants in the 
environment, l-.acli lile has an owner, thai is. a person who creates and maintains the lile. Sometimes a 
person can use dala with permission of the owner, or use data in a small "public file." which is usually 
read-only. 
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CHAPTER THREE: A CONCEPTUAL DBMS MODEL 95 




Figure 3-10. Userschema: Definition of a User's View of the Database. 

Every user has some perception of the structure ind conlent of ihe data being accessed at any given 
time. The userschema is a formal expression of the user"s view of the database. It consists of: 

• A logical data definition. 

• Its physical representation in a program buffer, or on the screen or output page of a user's 

terminal. 

• Its mapping to the data in the database. 

The userschema may use different data names, reflect a different data structure, and refer to only 
portions of the database. The DBMS knows both the userschema and the database schema and can convert 
the data when transferred between the two according to the defined mapping. The userschema is the funda- 
mental component of a DBMS architecture for achieving sharability and evolvability. 
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CHAPTER ELEVEN: DATA INDEPENDENCE. DATA CONVERSION. AND DATABASE REVISION 409 

As before, if the change to the schema only has an efficiency impact, it may be 
desirable to continue to execute the program with a fully defined userschema, omitting 
the fact that it was a copy of the (old) schema. The system would operate normally, 
testing for incompatibilities and performing any required conversions and transforma- 
tions. The less efficient execution would be an interim solution until the program could 
be rewritten as priority demands on the human resources would permit. Again, the 
central point is that the using organization has a choice, based purely on economic 
grounds — the cost of running inefficiently versus the cost of reprogramming in order to 
run more efficiently in the future. 

11.4 DATA CONVERSION PROCESSES 

A data conversion process takes data in one machine readable form and converts 
into another form. Data conversion lakes place during database creation, update, and in 
the schema-uscrschema mapping discussed earlier in this chapter. These processes are 
all members of a family of data conversion processes. 

Referring to Figure 11-9. a general data conversion process takes as input: 

• Existing mechanized data (in a database, an external file or a program buffer) called 

"source"' data for the conversion process. 

• Its complete definition, which may be separate and explicit, may be buried in a spe- 

cial-purpose conversion program, or may be assumed in a general conversion 
program which expects the existing data to be in a prescribed format and 
structure. 

• The definition of the new "target" data to be generated by the conversion process. The 

target data definition may be complete or it may be incremental to the source data 
definition. Also, the mapping between the two definitions may be completely 
implicit or partly explicit where the conversion process cannot infer the 

The conversion process produces as output: 

• A new collection of data (in a database, external file, or program buffer) which con- 

forms to the target data definition. 

11.4.1 The Family of Data Conversion Processes 

The family of data conversion processes includes mechanization, creation, update, 
revision, reversion.* and the schema to userschema conversion. These functions are 
shown in Figure 11-10 as they relate within the family. For clarity, the source and 
target data definitions required of each conversion process are not shown. 

In a DBMS it is highly desirable for data conversion to be performed by the same 
underlying modules in the database control system. The availability of rich data con- 
version facilities in each of the members of the family of conversion processes deter- 
mine the degree of overall data independence exhibited in the system, thus contributing 

*Also called file writing or file generation (see section 7.1.3). 
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chapter iour: logical data structures 121 



DATA STRUCTURES 
- GROUPED ITEMS - 



- SINGLE FILE - 



■i SINGLE FLAT FILE - A single record type with 

I 1 single-valued data items 

- no repeating items or groups of i 



■J SINGLE HIERARCHICAL FILE - a single entry type containing I 0RG UNrr I 

1 — f 1 nested repeating groups of items I — — I 



I PERSON I 



I ORG. UNIT I 



I PERSON "j | POSITION | | PROJECT j 
| SKILL [ 

■j MULTIFILE STRUCTURE I - data items grouped into multiple entry types 
1 - relationships defined between entry types (files) 

- some drop the term "file" and call this a "database" 

- each entry type (or "file") may have a flat 
or a hierarchical data structure (see SINGLE FILE) 



- GENERAL INTER FILE RELATIONSHIPS 

Many, Many:Many relationships HEAT^. 

PERSON ^POSITION | 

- UNGROUPED ITEMS - OBJECT- RELATION STRUCTURE I 



I ORG. UNIT I } 



Y RELATIONS BETWEEN OBJECT DOMAINS 
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for the first time on October 16, 2007, I understand that Knacta, Inc. has a license to the 
intellectual property associated with this application. I have had extrerneley brief 
discussion of this patent application and the article cited below with the inventor. 

On October 25, 2007 I was given a copy of "How to sort out the premium drivers 
of post deal value", by Daniel Bielinski published in Mergers and Acquisitions in July of 
1993. Until that time I had not read the article. However, I have read many articles on the 
subject of Value Based Management. I have a strong understanding of the concept and 
practice of Value Based Management and have been teaching this concept for over 10 
years. I have studied the entire article and I am totally familiar with the language of the 
article with the scope thereof. 

Based on my experience and education in the field of finance, I have concluded 
that the the Bielinski article and Value Based Management does not inherently describe 
or enable: the development of a computational model of enterprise market value by 
element of value and segment of value where the elements of value are selected from the 
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excess financial asset. 

There are several reasons for this: 

1 . As stated in the article VBM is similar to SVA. One of the ways it is similar is that 
it focuses on "value drivers" such as profit margin and growth instead of intangible 
assets as part of a tree based analysis of cash flow. Unlike SVA, VBM includes 
operational value drivers that drive the value drivers. However, these are generally 
not intangible elements of value. For example, Bielinski provides an example of 
breaking down profit margin by looking more closely at the cost of materials; 

2. VBM is also similar to SVA in that it relies on the efficient market theory and this 
precludes the analysis of market sentiment; 
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3. SVA and VBM are tools that focus on the standard valuation model, a discounted 
cash flow model, that does not even consider the value associated with flexibility 
or decision making that is done sequentially and conditionally based on the arrival 
of new information. The valuation of this flexibility is the basis for valuation using 
real option analysts; and 

4, Neither VBM or SVA address the valuation of derivatives. 
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of the application or any patents issuing thereon. 
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Abstract: 

An improved Genetic Algorithm based on Evolutionarily 
Stable Strategy is proposed to optimize the initial weights of 
BP network in this paper. The improvement of GA lies in the 
introducing of a new mutation operator under control of a 
stable factor, which is found to be a very simple and effective 
searching operator. The experimental results in BP neural 
network optimization show that this algorithm can effectively 
avoid BP network converging to local optimum. It is found by 
comparison that the improved genetic algorithm can almost 
avoid the trap of local optimum and effectively improve the 
convergent speed. 

Keywords: 

Evolutionarily stable strategy; Genetic algorithm; Neural 
network; Back propagation (BP) algorithm; Premature 
convergence 

1 Introduction 

In recent years, there have been many attempts in 
designing artificial neural networks automatically, in which 
the combination of evolutionary algorithms and neural 
networks has attracted a great deal of attention and one kind 
of evolutionary artificial neural network has been formed. 
Evolving neural networks by genetic algorithm were 
researched earliest of all. 

The efficiency of GA has great influences on BP neural 
network (BPNN) optimization. During application of GA, 
however, there often exists a problem of premature 
convergence and stagnation" 1 . Whitley think that selective 
pressure and selection noise are the main factors of 
affecting population diversity [2] . Higher selective pressure 
often leads to the loss of diversity in the population, which 
causes premature convergence at the same time of 
improving convergent speed. Therefore, keeping the 
balance between population diversity and convergent speed 
is very important to the performance of GA. 

In recent years, many diversity preservation methods 
have been developed to avoid premature convergence to a 
local optimum. These can be divided into the following 
three subclasses: 

1) Schemes of alleviating selective pressure to 
keep the biologic diversity, such as the modification of 
selection operator [3 ~ 51 and scale-transformation of fit 



function [6] . Unfortunately, these methods often cause 
another problem of slow rate of convergence or stagnation 
in searching global optimum at the same time of improving 
population diversity. 

'2)Non-slatic mutation rate control schemes 
including dynamic [7 ~ 101 , adaptive or self-adaptive [!0 " 121 
mechanism to control the rate of mutation. The mutation 
operator is a main operator to keep the biologic diversity, 
especially in real-coded GA, because it introduces new 
search space and maintain the genetic diversity of a 
population, whereas the crossover operator only operates in 
the known search space. From this point of view, high 
mutation rate is good for searching the global solution. But 
too high mutation rate will result in blind stochastic search. 
It has been proved that deterministically varying mutation 
rates during the se arch have a better performance compared 
to the fixed mutation rate schemes. Unfortunately, there are 
some drawbacks in non-static mutation rate control 
schemes. The dynamic parameter control scheme requires 
for the user to devise a schedule specifying the rate at 
which the parameter is typically decreased. The self- 
adaptive scheme does not need such a specific schedule. 
Unfortunately it is rather complicated to explain to novice 
users, and as a result they usually prefer the simple fixed 
mutation rate scheme. 

3)Spatial separation schemes 113 14] . One of the 
most important representatives is the distributed GA's 
(DGA's). Their premise lies in partitioning the population 
into several subpopulations, each one of them being 
processed by a GA independently of the others. 
Furthermore, a migration mechanism produces a 
chromosome exchange between the subpopulations. In this 
way, a distributed search and an effective local tuning may 
be obtained simultaneously. They are suitable for producing 
multi-resolution in search space but run risk of running too 
much CPU time. 

A genetic algorithm based on evolutionarily stable 
strategy (ESSGA) is proposed in this paper to try to pursue 
better balance between population diversity and convergent 
speed by means of introducing a new kind of mutation 
operator under the control of a stable factor. Different from 
other mutation rate control schemes, this mutation operator 
only acts on some of the preponderant individuals under the 
control of a stable factor, which keeps the ratio of quantity 
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faults in components of a multi-component system, where 
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more performance parameters x related to measurement 
parameters z that can be expressed as a function of the 
performance and operating parameters defining an operating 
condition of the system. The methods include: defining a 
series of fault classes corresponding to possible outcomes of 
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estimated values of said parameters and are constrained only 
to indicate fault affected values for performance parameters 
of the fault affected component of the respective class; and 
optimising an objective function which gives a measure of 
the consistency between measured and calculated values of 
t parameters. 



14 Claims, 8 Drawing Sheets 



Engine Measurements 



Component Fault / Instrument Fault 



D" 1 



^ Single/ Multiple Component ~| j Detect Faulty Sensor | ^ 



LPC | HPC | ICL| HPT| LPT| FPT | RCR | | Compressor Group 



GA Diagnostic Module 



Serial No.: 08/999,245 



58 



Related Proceedings Appendix 



09/761 ,671 - opinion appears to be based largely on an assumption that VBM is different than 
SVA in a number of areas where they are in fact the same (see pages 47 - 49). 



Serial No: 08/999,245 



59 



UNITED STATES PATENT AND TRADEMARK OFFICE 



BEFORE THE BOARD OF PATENT APPEALS 
AND INTERFERENCES 



Ex parte JEFFREY SCOTT EDER 



Appeal 2007-2745 
Application 09/761,671 
Technology Center 3600 



Decided: August 29, 2007 



Before TERRY J. OWENS, HUBERT C. LORIN, and ANTON W. FETTING, 
Administrative Patent Judges. 

FETTING, Administrative Patent Judge. 

DECISION ON APPEAL 



STATEMENT OF CASE 
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